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Abstract 

Eff is a programming language based on the algebraic approach to computa¬ 
tional effects, in which effects are viewed as algebraic operations and effect han¬ 
dlers as homomorphisms from free algebras. Eff supports first-class effects and 
handlers through which we may easily define new computational effects, seam¬ 
lessly combine existing ones, and handle them in novel ways. We give a de- 
notational semantics of eff and discuss a prototype implementation based on it. 
Through examples we demonstrate how the standard effects are treated in eff , and 
how eff supports programming techniques that use various forms of delimited con¬ 
tinuations, such as backtracking, breadth-first search, selection functionals, coop¬ 
erative multi-threading, and others. 


Introduction 

Eff is a programming language based on the algebraic approach to effects, in which 
computational effects are modelled as operations of a suitably chosen algebraic the¬ 
ory Ell- Common computational effects such as input, output, state, exceptions, and 
non-determinism, are of this kind. Continuations are not algebraic m , but they turn out 
to be naturally supported by eff as well. Effect handlers are a related notion flH ED 
which encompasses exception handlers, stream redirection, transactions, backtracking, 
and many others. These are modelled as homomorphisms induced by the universal 
property of free algebras. 

Because an algebraic theory gives rise to a monad ifTTl . algebraic effects are sub¬ 
sumed by the monadic approach to computational effects Q). They have their own 
virtues, though. Effects are combined more easily than monads a, and the interaction 
between effects and handlers offers new ways of programming. An experiment in the 
design of a programming language based on the algebraic approach therefore seems 
warranted. 

Philip Wadler once opined 03 that monads as a programming concept would not 
have been discovered without their category-theoretic counterparts, but once they were, 
programmers could live in blissful ignorance of their origin. Because the same holds 
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for algebraic effects and handlers, we streamlined the paper for the benefit of program¬ 
mers, trusting that connoisseurs will recognize the connections with the underlying 
mathematical theory. 

The paper is organized as follows. Section [l] describes the syntax of eff, Section [2] 
informally introduces constructs specific to eff, Section [3] is devoted to type check¬ 
ing, in Section [4] we give a domain-theoretic semantics of eff, and in Section [5] we 
briefly discuss our prototype implementation. The examples in Section [6] demonstrate 
how effects and handlers can be used to produce standard computational effects, such 
as exceptions, state, input and output, as well as their variations and combinations. 
Further examples show how eff’s delimited control capabilities are used for nondeter- 
ministic and probabilistic choice, backtracking, selection functionals, and cooperative 
multithreading. We conclude with thoughts about the future work. 

The implementation of eff is freely available at http: //math. andr e j . com/e f f /. 

Acknowledgements We thank Ohad Kammar, Gordon Plotkin, Alex Simpson, and 
Chris Stone for helpful discussions and suggestions. Ohad Kammar contributed parts 
of the type inference code in our implementation of eff. The cooperative multithreading 
example from Section [OP] was written together with Chris Stone. 

1 Syntax 

Eff is a statically typed language with parametric polymorphism and type inference. 
Its types include products, sums, records, and recursive type definitions. To keep to the 
point, we focus on a core language with monomorphic types and type checking. The 
concrete syntax follows that of OCaml J6), and except for new constructs, we discuss 
it only briefly. 

1.1 Types 

Apart from the standard types, eff has effect types E and handler types A => B\ 

A,B,C ::= int | bool | unit | empty | (type) 

AxB | A + B | A^B | E \ A=> B, 

E :: = effect (operation op^: A, —»• Bf)i end. (effect type) 

In the rule for effect types and elsewhere below (• • • )j indicates that • • • may be re¬ 
peated a finite number of times. We include the empty type as we need it to describe 
exceptions, see Section [612] An effect type describes a collection of related operation 
symbols, for example those for writing to and reading from a communication channel. 
We write op: A —y B 6 E or just op e E to indicate that the effect type E contains 
an operation op with parameters of type A and results of type B. The handler type 
A =>■ B should be understood as the type of handlers acting on computations of type A 
and yielding computations of type B. 
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1.2 Expressions and computations 

Eff distinguishes between expressions and computations , which are similar to values 
and producers of fine-grain call-by-value m. The former are inert and free from com¬ 
putational effects, including divergence, while the latter may diverge or cause computa¬ 
tional effects. As discussed in Section[5] the concrete syntax of eff hides the distinction 
and allows the programmer to freely mix expressions and computations. 

Beware that we use two kinds of vertical bars below: the tall | separates grammat¬ 
ical alternatives, and the short | separates cases in handlers and match statements. The 
expressions are 

e ::= x \ n \ c | true | false | () | (ei,e2) | (expression) 

Left e | Right e | fun a;:i4c | e#op | h, 
h ::= handler (e* # opi xk i-» Cj)j | val x c v \ finally x\ ->■ c/, (handler) 

where x signifies a variable, n an integer constant, and c other built-in constants. The 
expressions (), (ei, e^). Left e, Right e, and fun x: A c are introduction forms 
for the unit, product, sum, and function types, respectively. Operations e#op and 
handlers h are discussed in Section |2 
The computations are 

c ::= vale | let x = C\ in C2 | let rec fx = C\ in C2 | (computation) 
if e then ci else C2 | match e with | match e with (x, y~) i->- c | 
match e with Left x 1 —l C\ | Right y > C2 | e.\ ei | 
new E | new E @ e with (operation opj x@y i-»- c,)j end | 
with e handle c. 

An expression e is promoted to a computation with val e, but in the concrete syntax 
val is omitted, as there is no distinction between expressions and computations. The 
statement let x = C\ in C2 binds x in C2, and let rec f x = C\ in C2 defines 
a recursive function / in C2. The conditional statement and the variations of match 
are elimination forms for booleans, the empty type, products, and sums, respectively. 
Instance creation and the handling construct are discussed in Section [2] 

Arithmetical expressions such as e\ + e-i count as computations because the arith¬ 
metical operators are defined as built-in constants, so that e\ + e2 is parsed as a double 
application. This allows us to uniformly treat all operations, irrespective of whether 
they are pure or effectful (division by zero). 

2 Constructs specific to eff 

We explain the intuitive meaning of notions that are specific to eff, namely instances, 
operations, handlers, and resources. We allow ourselves some slack in distinguishing 
syntax from semantics, which is treated in detail in Section |4] It is helpful to think of 
a terminating computation as evaluating either to a value or an operation applied to a 
parameter. 
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2.1 Instances and operations 

The computation new E generates a fresh effect instance of effect type E. For example, 
new ref generates a new reference, new channel a new communication channel, 
etc. The extended form of new creates an effect instance with an associated resource, 
which determines the default behaviour of operations and is explained separately in 
Section [231 

For each effect instance e of effect type E and an operation symbol op e E there 
is an operation e # op, also known as a generic effect tm By itself, an operation is a 
value, and hence effect-free, but an applied operation e # op e' is a computational effect 
whose ramifications are determined by enveloping handlers and the resource associated 
with e. 


2.2 Handlers 

A handler 

h = handler (ei#op i xk i->- c*)* | val x c„ | finally x\Cf 
may be applied to a computation c with the handling construct 

with h handle c, (1) 

which works as follows (we ignore the finally clause for the moment): 

1. If c evaluates to val e, ([T) evaluates to c v with x bound to e. 

2. If the evaluation of c encounters an operation e, # op i e, ([TJ evaluates to c, with 
x bound to e and k bound to the continuation of e t # op, e, i.e., whatever remains 
to be computed after the operation. The continuation is delimited by ([T]» and is 
handled by h as well. 

The f inally clause can be thought of as an outer wrapper which performs an addi¬ 
tional transformation, so that (|Tji is equivalent to 

let x = (with h' handle c) in Cf 

where h' is like h without the finally clause. Such a wrapper is useful because we 
often perform the same transformation every time a given handler is applied. For ex¬ 
ample, the handler for state handles a computation by transforming it to a function ac¬ 
cepting the state, and finally applies the function to the initial state, see Section [63] 
If the evaluation of c encounters an operation e # op e! that is not listed in h, the 
control propagates to outer handling constructs, and eventually to the toplevel, where 
the behaviour is determined by the resource associated with e. 

2.3 Resources 

The construct 


new E @ e with (operation op^ x @ y i->- 6j)j end 


creates an instance n with an associated resource , inspired by coalgebraic semantics of 
computational effects 02] Q3). A resource carries a state and prescribes the default be¬ 
haviour of the operations n # op,. The paradigmatic case of resources is the definition 
of ML-style references, see Section [63] 

The initial resource state for n is set to e. When the toplevel evaluation encounters 
an operation n # op, e', it evaluates c % with x bound to e! and y bound to the current 
resource state. The result must be a pair of values, the first of which is passed to the 
continuation, and the second of which is the new resource state. If c, evaluates to 
an operation rather than a pair of values, a runtime error is reported, as there is no 
reasonable way of handling it. 

In eff the interaction with the real world is accomplished through built-in resources. 
For example, there is a predefined channel instance std with operations std#read 
and std#write whose associated resource performs actual interaction with the stan¬ 
dard input and the standard output. 


3 Type checking 

Types in eff are like those of ML m in the sense that they do not capture any informa¬ 
tion about computational effects. There are two typing judgements, T h e e: A states 
that expression e has type A in context T, and T |- c c: A does so for a computation c. 
As usual, a context T is a list of distinct variables with associated types. The standard 
typing rules for expressions are: 

x * -A g r 

- Tl- e n:int T h e true : bool T h e false : bool 

T\~ e x:A 

r he ei : A r h e e 2 :B T h e e : A 

F h Q : unit -—-—- -- 

r h e (ei,e 2 ) :A x B T h e Left e : A + B 


T \- e e : B T,x: Ab- C c: B 

T K Right e : A + B T h e fun x:At-4-c:A^rB 

We also have to include judgements that assign types to other built-in constants. An 
operation receives a function type 

r h e e: E op : A — > B £ E 

T h e e # op : A —» B 

while a handler is typed by the somewhat complicated rule 


T h e e,-: Ej, op ,: Ai B{ £ Ei 
T, a;: Aj, fc : B t -> B F c q : B 


T, x: B \- c c f : C 


T b e (handler (ej#op t xk i-> cffji \ val x i-> Cu \ finally x i-> c/) :A=>C 


which states that a handler first handles a computation of type A into a computation 
of type B according to the val and operation clauses, after which the finally clause 
transforms it further into a computation of type C. 
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The typing rules for computations are familiar or expected. Promotions of expres¬ 
sions and let statements are typed by 

1? t~ e e : A T h c Ci: A T,x: A\- c c 2 : B 

T b c val e: A T b c let x = c\ in C2 : B 

T, /: A -> B, x : A b c d : B T, f : A -> B b c c 2 :C 
F b c let rec f x = c\ in C2 : C 

and various elimination forms are typed by 

T |- e e: bool T b c Ci: A T b c c 2 : A T |- e e: empty 

T |- c if e then ci else C2 : A T b c match e with: A 

T b e e: A x B T,x: A,y: B \- c c:C 
T b c match e with Qx, y') c:C 

T b e e : A + B T, x : A b c Ci: C T,y:B\- c c 2 :C 
F b c match e with Left x i-> Ci | Right y\-^c 2 :C 

T b e ei: A -> B T b e e 2 : A 
T b c ei e 2 : B 

The instance creation is typed by the rules 

T b c new E:E 

T b e e : C 1 o Pi : Ai ^ Bi £ E T, x : A u y : C b c a : Bi x C 
T b c new E @ e with (operation op ; x @ y i->- Cj)i end : E 

The rule for the simple form is obvious, while the one for the extended form checks 
that the initial state e has type C and that, for each operation op ?: : A, —>■ Bj 6 E, the 
corresponding computation d evaluates to a pair of type B t x C. 

Finally, the rule for handling expresses the fact that handlers are like functions: 

T b c e: A Tb e e:A=>B 
T b c with e handle c : B 

4 Denotational semantics 

Our aim is to describe a denotational semantics which explains how programs in eff 
are evaluated. Since the implemented runtime has no type information, we give Curry- 
style semantics in which terms are interpreted without being typed. See the exposition 
by John Reynolds oa on how such semantics can be related to Church-style semantics 
in which types and typing judgements receive meanings. 
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We give interpretations of expressions and computations in domains of values V 
and results R, respectively. We follow Reynolds by avoiding a particular choice of V 
and R , and instead require properties of V and R that ensure the semantics works out. 
The requirements can be met in a number of ways, for example by solving suitable 
domain equations or by taking V and R to be sufficiently large universal domains. 

The domain V has to contain integers, booleans, functions, etc. In particular, we 
require that V contains the following retracts, where I is a set of effect instances, and 
© is coalesced sum: 


z. . < -* v {o, i }_l 


v {4a v *2 Jg y 


I_l V V x V 


V 


V 


R v 


v rh < 


As expressions are terminating, the bottom element of V is never used to denote diver¬ 
gence, but we do use it to indicate ill-formed values and runtime errors. 

The domain 

(T + IxOxFxfi v )i (2) 

embodies the idea that a terminating computation is either a value or an operation 
applied to a parameter and a continuation. There are canonical retractions from |2]i 
onto the two summands, 


V - < tv>1 " (f + IxOxFx R v ) ± < '° Per » (IxOxkx R v ) ± 

(3) 

A typical element of ([2} is either JL, of the form i val (v) for a unique v G V, or of the 
form i oper (n. op, v, k) for unique n £ I, op € O, v G V, and k £ R v . We require that 
R contains ([2| as a retract: 

(T + !xOxFxF)i ^- ' reS *R. (4) 

We may dehne a strict map from |2| by cases, with one case specifying how to map 
tvai(u) and the other how to map toper {n, op, v, k). For example, given a map / : V —x 
R, there is a unique strict map /* : (V + IxOxFx R v )± —x R, called the lifting 
of /, which depends on / continuously and satisfies the recursive equations 

fHhM) =f(v), 

/ f (toper (n, op, V, k)) = L oper (n, Op, V, / f O p Ies O K ). 


An environment rj is a map from variable names to values. We denote by r] [x v\ 
the environment which assigns v to x and otherwise behaves as r/. An expression is 
























interpreted as a map from environments to values. The standard cases are as follows: 


H v = v(x) 

M V = 

[false]?? = tbooi(O) 

[true]?? = t boo i(l) 

[0]?? = WtW 

[Cei, e 2 )] ?? = ? x ([ei] ??, [e 2 ] rj) 

[Left e]?? = 4 + (to([eJ ??)) 

[Right e]?? = t+(ti([e] ??)) 

[fun x : A 1-4 c] ?? = i^{\v : V . [c] rj[x 1-4 u]) 

Of course, we need to provide the semantics of other built-in constants, too. The inter¬ 
pretation of e # op make sense only when e evaluates to an instance, so we define 

f » nT1 , n / i-j. (Xv : V. L res (i oper (n, op, v, ? res o t val ))) if p effect (|e]t))=ng I, 
The interpretation of a handler is 

[handler (e» # op i xk i-> c,)j | val x i-4 c v \ finally x \-4 c/] ?? = 

o p les o h o p les ) 

where / : V -4 R is f(v) = [c/] r)[x 1-4 ?:] and /i:(V + IxOxVx R v )± R is 
characterized as follows: if one of the p e ffect ([e»] ??) is _L we set h = Xx . _L, otherwise 
Peffect ([ej] rj) = n, G I for all i and then we take the h defined by cases as 

h(t va i(v)) = \cy\rj\x u] 

h(o op er{ni, op i; v, k)) = [q] T][x v, k ^ k\ for all i, 

h{iopei{n, op, V, k)) = (-res(toper(«, °P, V,ho p res O «)) 

if (n, op) ^ ( rii , opj for all i. 

We proceed to the meaning of computations, which are interpreted as maps from 
environments to results. Promotion of expressions is interpreted in the obvious way as 

[val e] ?? = tres(ival([e] ??)) 

The let statement corresponds to monadic-style binding: 

[let x = ci in c 2 ] ?? = (Xv : V . [c 2 ] ??[or i-4 u]) t (p res ([ci] ??)), 

A recursive function definition is interpreted as 


[let rec f x = <% in c 2 ] rj = [c 2 ] ??[/ i-4 t_,(f)] 



where t : V —tR.K the least fixed point of the map 


f H- (Xv : V . [ci] r][f h-X i^{t),x i-X u]). 

The elimination forms are interpreted in the usual way as: 

f[ci]r? if p b ooi[eJ r? = 1 
[if e then c x else c 2 ] r? = < [c 2 1 r? if p b ooi[e] r? = 0 
[ _L otherwise 
[match e with] y — _L 

[match e with (x, y~) !->• c] rj = [c] y[x h-X Uo, y i->- t/J 

where (v 0 , ui) = p x ([e] rj) 

( [ci] ??[x v] if p+([e]r?) = toO 

[match e with Left x !->• Ci | Right y ^ c 2 jr] = < [c 2 ] r)[y ^ v] if p+([e] rj) = ii(t 
[ _L otherwise 

[ei e 2 ] rj = P->([ei] t?)([e 2 ] rj) 

For the interpretation of new we need a way of generating fresh names so that we may 
sensibly interpret 

[new EJr} = t r es(ivai(teffect(«))) where n £ I is fresh. 

The implementation simply uses a local counter, but a satisfactory semantic solution 
needs a model of names, such as the permutation models of Pitts and Gabbay Co), with 
I then being the set of atoms. 

Finally, the handling construct is just an application 

[with e handle c] 77 = p=».([e] t?)([c] rj). 


4.1 Semantics of resources 

To model resources, the denotational semantics has to support the mutable nature of 
resource state, for example by explicitly threading it through the evaluation. But we 
prefer not to burden ourselves and the readers with the ensuing technicalities. Instead, 
we assume a mutable store a indexed by effect instances which supports the lookup 
and update operations. That is, cr[n] gives the current contents at location n e I, while 
a[n] <H v ; x sets the contents at location n to v £ V and yields x. 

A resource describes the behaviour of operations, i.e., it is a map OxFxF^ 
V X V which computes a value and the new state from a given operation symbol, 
parameter, and the current state. Thus an effect instance is not just an element of I 
anymore, but an element of J = I X (V x V) 0xl/xV ’. Consequently in the semantics 
we replace I with J throughout and adapt the semantics of new so that it sets the initial 
resource state and gives an element of JT: 

[new E @ e with (operation op.^ x @ y i-X cj )j end] 77 = 

a[n] x-h [e] y ; t ies (i val (i ef fect (n, r))) where n G I is fresh 
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where r:QxFxF—^FxFis defined by 



Px(Pval(Pre S ([[Ci]r?[a; !->• V, 


_L 


y l— ^ s]))) if op = opj for some i, 
otherwise. 


If no resource is provided, we use a trivial one: 

[new E\r} = 4rea(ivai(teffect(n, -L))) where n G I is fresh. 

Finally, to model evaluation at the toplevel, we define £ : (V+lxOx V x R v )± —>■ 
V by cases: 


£(tval («)) = V 

£(ioper((n,r),op,v,K)) = <j[n\ <-is; £(p res (W)) 

where (v',s) = r(op,u, cr[n]). 


The meaning of a computation c at the toplevel in the environment 77 (and an implicit 
resource state a) is £(p res ([c] 77 )). 

5 Implementation 

To experiment with eff we implemented a prototype interpreter whose main evaluation 
loop is essentially the same as the denotational semantics described in Section[4] Apart 
from inessential improvements, such as recursive type definitions, inclusion of for 
and while loops, and pattern matching, the implemented language differs from the 
one presented here in two ways that make it usable: we implemented Hindley-Milner 
style type inference with parametric polymorphism and in the concrete syntax we 
hid the distinction between expressions and computations. We briefly discuss each. 

There are no surprises in the passage from monomorphic type checking to paramet¬ 
ric polymorphism and type inference. The infamous value restriction m is straight¬ 
forward because the distinction between expressions and computations corresponds 
exactly to the distinction between nonexpansive and expansive terms. In fact, it may be 
worth investing in an effect system that would relax the value restriction on those com¬ 
putations that can safely be presumed pure. Because new E is a computation, effect 
instances are not polymorphic, which is in agreement with ML-style references being 
non-poly morphic. 

A syntactic division between pure expressions and possibly effectful computa¬ 
tions is annoying because even something as simple as fxy has to be written as 
let g = f x in gy, and having to insert val in the right places is no fun either. 
Therefore, the concrete syntax allows the programmer to arbitrarily mix expressions 
and computations, and a desugaring phase appropriately separates the two. 

The desugaring process is fairly simple. It inserts a val when an expression stands 
where a computation is expected. And if a computation stands where an expression is 
expected, the computation is hoisted to an enclosing let statement. Because several 
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computations may be hoisted from a single expression, the question arises how to order 
the corresponding let statements. For example, (/ x, g y ) can be desugared as 

let a = f x in let b = gy in 

let b = g y in (a, b) let a = f x in (a, b) 

The order of / x and g y matters when both computations cause computational effects. 
The desugaring phase avoids making a decision by using the simultaneous let state¬ 
ment 

let a = / x and b = g y in (a, b) 

which leaves open the possibility of various compiler optimizations. The prototype 
simply evaluates simultaneous bindings in the order they are given, and a command¬ 
line option enables sequencing warnings about possible unexpected order of effects. It 
could be argued that the warnings should actually be errors, but we allow some slack 
until we have an effect system that can detects harmless instances of simultaneous 
binding. 

For one-off handlers, ejf provides an inline syntax so that one can write 


handle 

with 


instead of 


with 

handler 

handle 


Additionally, the val and finally clauses may be omitted, in which case they are 
assumed to be the identities. 


6 Examples 

In this section we consider a number of examples that demonstrate the possibilities 
offered by first-class effects and handlers. Functional programmers will notice similar¬ 
ities with the monadic programming style, and continuations aficionados will recognize 
their favourite tricks as well. The point we are making though is that even though mon¬ 
ads and continuations can be simulated in ejf, it is usually more natural to use effects 
and handlers directly. 

6.1 Choice 

We start with an example that is infrequently met in practice but is a favourite of the¬ 
oreticians, namely (nondeterministic) choice. A binary choice operation which picks a 
boolean value is described by an effect type with a single operation decide: 

type choice = effect 

operation decide : unit -> bool 
end 


Let c be an effect instance of type choice: 




let c = new choice 
The computation 

let x = (if c#decide O then 10 else 20) in 
let y = (if c#decide () then 0 else 5) in 
x - y 

expresses the fact that x receives either the value 1® or 2®, and y the value Q or 5. If we 
ran the above computation we would just get a message about an uncaught operation 
c#decide. For the computation to actually do something we need to wrap it in a 
handler. For example, if we want c#decide to always choose true, we handle the 
operation by passing true to the continuation k: 
handle 

let x = (if c#decide () then 10 else 20) in 
let y = (if c#decide () then 0 else 5) in 
x - y 

with 

I c#decide () k -> k true 

The result of course is 1®. A more interesting handler is one that collects all possible 
results. Because we are going to use it several times, we define a handler (the operator 
@ is list concatenation): 

let choose_all d = handler 

I d#decide () k -> k true @ k false 
| val x -> [x] 

Notice that the handler calls the continuation k twice, once for each choice, and it 
concatenates the two lists so obtained. It also transforms a value to a singleton list. 
When we run 

with choose_all c handle 

let x = (if c#decide () then 10 else 20) in 

let y = (if c#decide () then 0 else 5) in 

x - y 

the result is the list [1®; 5; 2®; 15]. Let us see what happens if we use two instances 
of choice with two handlers: 

let cl = new choice in 
let c2 = new choice in 

with choose_all cl handle 
with choose_all c2 handle 

let x = (if cl#decide () then 10 else 20) in 

let y = (if c2#decide () then 0 else 5) in 

x - y 

Now the answer is [ [1®; 5]; [2®; 15] ] because the outer handler runs the inner one 
twice, and the inner one produces a list of two possible results each time. If we switch 
the order of handlers and of operations, 
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let cl = new choice in 
let c2 = new choice in 

with choose_all c2 handle 
with choose_all cl handle 

let y = (if c2#decide O then 0 else 5) in 
let x = (if cl#decide () then 10 else 20) in 
x - y 

the answer is [[1©; 20] ; [5;15]]. For a true understanding of what is going on, the 
reader should figure out why we get a list of four lists, each containing two numbers, 
if we switch only the order of handlers but not of operations. 

6.2 Exceptions 

An exception is an effect with a single operation raise with an empty result type: 

type ’a exception = effect 

operation raise : ’a -> empty 
end 

The parameter of raise carries additional data that can be used by an exception han¬ 
dler. The empty result type indicates that an exception, once raised, never yields the 
control back to the continuation. Indeed, as there are no expressions of the empty type 
(but there are of course computations of the empty type), a handler cannot restart the 
continuation of raise, which matches the standard behaviour of exception handlers. 

In practice, most exception handlers are one-off and are written using the inline 
syntax discussed in Section [3] There are also convenient general exceptions handlers, 
for example, 

let optionalize e = handler 
| e#raise _ _ -> None 
| val x -> Some x 

converts a computation that possibly raises the given exception e to one that yields an 
optional result. We can use it as follows: 
with optionalize e handle 
computation 

In ML-style languages exceptions can be raised anywhere because raise is polymor¬ 
phic, whereas in ejf we cannot use e# raise e' freely because its type is empty, not 
polymorphic. This is rectified with the convenience function 
let raise e x = match (e#raise x) with 

of type a exception —► a —>• /3 which eliminates the empty type, so we may use 
raise e e' anywhere. 

Another difference between ML-style exceptions and those in ejf is that the former 
are like a single instance of the latter, i.e., if we were to mimic ML exceptions in ejf we 
would need a (dynamically extensible) datatype of exceptions exc and a single instance 
e of type exc exception. The definition of raise would be 
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let raise x = match (e#raise x) with 

and exception handling would be done as usual. One consequence of this is that in ML 
it is possible to catch all exceptions at once, whereas in eff locally created exception 
instances are unreachable, just as local references are in ML. Which brings us to the 
next example. 

6.3 State 

In eff state is represented by a computational effect with operations for looking up and 
updating a value: 

type ’a ref = effect 

operation lookup: unit -> ’a 
operation update: ’a -> unit 
end 

We refer to instances of type ref as references. To get the same behaviour as in ML, 
we handle them with 

let state r x = handler 
| val y -> (fun s -> y) 

| r#lookup O k -> (fun s -> k s s) 

I r#update s’ k -> (fun s -> k () s’) 

| finally f -> f x 

The handler passes the state around by converting computations to functions that accept 
the state. For example, lookup takes the state s and passes it to the continuation k. 
Because k s is handled too, it is again a function accepting state, so we pass s to k s 
again, which explains why we wrote k s s. Values and updates are handled in a similar 
fashion. The finally clause applies the function so obtained to the initial state x. 

The above handler is impractical because for every use of a reference we have to 
repeat the idiom 

let r = new ref in 

with state r x handle 
computation 

An even bigger problem is that the reference may propagate outside the scope of its 
handler where its behaviour is undefined, for instance encapsulated in a A-abstraction. 
The perfect solution to both problems is to use resources as follows: 

let ref x = 

new ref @ x with 

operation lookup () @ s -> (s, s) 
operation update s’ @ _ -> (() , s’) 
end 

With this definition a reference carries a current state which is initially set to x, lookup 
returns the current state without changing it, while update returns the unit and changes 
the state. With the definition of the operators 
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let (!) r = r#lookup () 
let (:=) r v = r#update v 

we get exactly the ML syntax and behaviour. Of course, a particular reference may still 
be handled by a custom handler, for example to fetch its initial value from an external 
persistent storage and save the final value back into it. 

6.4 Transactions 

We may handle lookup and update so that the state remains unchanged in case an 
exception occurs. The handler which accomplishes this for a given reference r is 

let transaction r = handler 

| r#lookup () k -> (fun s -> k s s) 

| r#update s’ k -> (fun s -> k () s’) 

| val x -> (fun s -> r := s; x) 

| finally f -> f !r 

The handler passes around temporary state s, just like the state handler in Section [63] 
and only commits it to r when the handled computation terminates with a value. Thus 
the computation 

with transaction r handle 
r := 23; 

raise e (3 * !r); 
r := 34 

raises the exception e with parameter 69, but does not change the value of r. 

6.5 Deferred computations 

There are many variations on store, of which we mention just one that can be imple¬ 
mented with resources, namely lazy or deferred computations. Such a computation 
is given by a thunk, i.e., a function whose domain is unit. If and when its value is 
needed, the thunk is forced by application to (), and the result is stored so that it can 
be given immediately upon subsequent forcing. This idea is embodied in the effect 
type 

type ’a lazy = effect 

operation force: unit -> ’a 
end 

together with functions for creating and forcing deferred expressions: 
type ’a deferred = Value of ’a | Thunk of (unit -> ’a) 
let lazy t = 

new lazy @ (Thunk t) with 
operation force () @ v -> 

(match v with 

I Value v -> (v, Value v) 

| Thunk t -> let v = t () in (v, Value v)) 
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end 

let force d = d#force () 

The function lazy takes a thunk t and creates a new instance whose initial state is 
Thunk t. The first time the instance is forced, the thunk is evaluated to a value v, and 
the state changes to Value v. Thereafter the stored value is returned immediately. 

If the thunk triggers an operation, eff reports a runtime error because it does not 
allow operations in resources. While this may be seen as an obstacle, it also promotes 
good programming habits, for one should not defer effects to an unpredictable future 
time. It would be even better if deferred effectful computations were prevented by a 
typing discipline, but for that we would need an effect system. 

6.6 Input and output 

A program worth running has to connect with the real-world environment in some way. 
In eff this is done cleanly through built-in effect instances that provide an interface to 
the operating system. For input and output eff has a predefined effect type 

type channel = effect 

operation read : unit -> string 
operation write : string -> unit 
end 

and a channel instance std which actually writes to standard output and reads from 
standard input. Of course, we may handle std just like any other instance, for example 
the handler 

handler std#write _ k -> k () 
erases all output, while 

let accumulate = handler 

| std#write x k -> let (v, xs) = k () in (v, x :: xs) 

| val v -> (v, []) 

intercepts output and accumulates it in a list so that 
with accumulate handle 

std#write "hello"; std#write "world"; 3 * 14 

prints nothing and evaluates to (42, ["hello" ; "world"]). Similarly, one could 
feed the input from a list with the handler 
let read_from_list 1st = handler 

I std#read () k -> (fun (s::lst’) -> k s 1st’) 

| val x -> (fun _ -> x) 

I finally f -> f 1st 

Both handlers can be quite useful for unit testing of interactive programs. 
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6.7 Ambivalent choice and backtracking 

We continue with variations of choice from Section 16711 Recall that ambivalent choice 
is an operation which selects among several options in such a way that the overall 
computation succeeds. We first define the relevant types: 
type ’a result = Failure | Success of ’a 

type ’a selection = effect 

operation select : ’a list -> ’a 
end 

The handler which makes select ambivalent is 

let amb s = handler 
I s#select 1st k -> 

let rec try = function 
| [] -> Failure 
| x::xs -> (match k x with 

I Failure -> try xs 
I Success y -> Success y) 


try 1st 

Given a list of choices 1st, the handler passes each one to the continuation k in turn 
until it finds one that succeeds. The net effect is a depth-first search with which we 
may solve traditional problems, such as the 8 queens problem: 

let no_attack (x,y) (x’,y’) = 

x <> x' && y <> y’ && abs (x - x’) <> abs (y - y’) 


let available x qs = 

filter (fun y -> forall (no_attack (x,y)) qs) 

[I; 2; 3 ; 4; 5 ; 6; 7; 8] 

let s = new selection in 
with amb s handle 

let rec place x qs = 

if x = 9 then Success qs else 

let y = s#select (available x qs) in 
place (x+1) ((x,y) :: qs) 
in place 1 [] 

The function filter computes the suhlist of those elements in a list that satisfy the 
given criterion. The auxiliary function available computes a list of available rows in 
column x if queens qs have been placed onto the board so far. As usual, the program 
places the queens onto the board by increasing column numbers: given a column x 
and the list qs of the queens placed so far, an available row y is selected for the next 
queen. Because the backtracking logic is contained entirely in the handler, we may 
easily switch from a depth-first search to a breadth-first search by replacing only the 
amb handler with 
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let bfs s = 

let q = ref [] in 
handler 

I s#select 1st k -> 

(q := !q @ (map (fun x -> (k,x)) 1st) ; 
match !q with 
I [] -> Failure 

I (k,x) :: 1st -> q := 1st ; k x) 

The bfs handler maintains a stateful queue q of choice points (k,x) where k is a 
continuation and x an argument to be passed to it. The select operation enqueues 
new choice points, dequeues a choice point, and activates it. 

The fact that bfs seamlessly combines a stateful queue with multiple activations of 
continuations may lure one into writing an imperative solution to the 8 queens problem 
such as 

let s = new selection in 
with amb s handle 

let qs = ref [] in 

for x = 1 to 8 do 

let y = s#select (available x !qs) in 
qs := (x, y) :: ! qs 
done ; 

Success !qs 

However, because qs is handled with a resource outside the scope of amb a queen once 
placed onto the board is never taken off, so the search fails. To make sure that amb 
restores the state when it backtracks, the state has to be handled inside its scope: 

let s = new selection in 
with amb s handle 

let qs = new ref in 

with state qs [] handle 
for x = 1 to 8 do 

let y = s#select (available x !qs) in 
qs := (x, y) : : ! qs 
done ; 

Success !qs 

The program finds the same solution as the first version. The moral of the story is that 
even though effects combine easily, their combinations are not always easily under¬ 
stood. 


6.8 Selection functionals 

The amb handler finds an answer if there is one, but provides no information on the 
choices it made. If we care about the choices that lead to a particular answer we proceed 
as follows. First we adapt the select operation so that it accepts a choice point as well 
as a list of values to choose from: 

type (’a, ’b) selection = effect 
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operation select: ’a * ’b list -> ’b 
end 

The idea is that we would like to record which value was selected at each choice point. 
Also, multiple invocations of the same choice point should all lead to the same selec¬ 
tion. The handler which performs such a task is 

let select s v = handler 

I s#select (x,ys) k -> (fun cs -> 

(match assoc x cs with 
I Some y -> k y cs 
I None -> 

let rec try = function 
| [] -> Failure 
I y::ys -> 

(match k y ((x,y)::cs) with 

I Success 1st -> Success 1st 
| Failure -> try ys) 
in try ys)) 

| val u -> (fun cs -> 

if u = v then Success cs else Failure) 

| finally f -> f [] ;; 

The function assoc performs lookup in an associative list. The handler keeps a list 
cs of choices made so far. It handles select by reusing a choice that was previously 
recorded in cs, if there is one, or else by trying in turn the choices ys until one suc¬ 
ceeds. A value is handled as success if it is the desired one, and as a failure otherwise. 

A simple illustration of the handler is a program which looks for a Pythagorean 
triple: 

let s = new selection in 
with select s true handle 

let a = s#select ("a", [5 ; 6;7;8]) in 
let b = s#select ("b", [9;1®;11;12]) in 
let c = s#select ("c", [13 ; 14;15;16]) in 
a*a + b*b = c*c 

It evaluates to Success [("c", 13); ("b", 12); ("a", 5)]. 

Martin Escardo’s “impossible” selection functional m may be implemented with 
our selection handler. Recall that the selection functional e accepts a propositional 
function p : 2 N —y 2 and outputs x 6 2 pf such that p(x) = 1 if, and only if, there exists 
y £ 2 n such that p(y) = I. Such an x can be found by passing to p an infinite sequence 
of choice points, each selecting either false or true, as follows: 

let epsilon p = 

let s = new selection in 

let r = (with select s true handle 

p (fun n -> s#select (n, [false; true]))) 

match r with 

I Failure -> (fun _ -> false) 
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I Success 1st -> 

(fun n -> match assoc n 1st with 

I None -> false | Some b -> b) 

The select handler either fails, in which case it does not matter what we return, or 
succeeds by computing a list of choices for which p evaluates to true. In other words, 
r is a basic open neighbourhood on which p evaluates to true, and we simply return 
one particular function in the neighbourhood. 

There are several differences between our implementation and Escardo’s Haskell 
implementation. First, our implementation is not recursive, or to be more precise, it 
only employs structural recursion and whatever recursion is contained in p. Second, we 
compute a basic neighbourhood on which p evaluates to true and then pick a witness 
in it, whereas the Haskell implementation directly computes the witness. Third, and 
most important, we heavily use the intensional features of eff to direct the search, i.e., 
we pass a specially crafted argument to p which allows us to discover how p uses its 
argument. The result is a more efficient implementation of epsilon, which however 
is not extensional. A Haskell implementation must necessarily be extensional, because 
all total functionals in Haskell are. 

6.9 Probabilistic choice 

Probabilistic choice is a form of nondeterminism in which choices are made according 
to a probability distribution. For example, we might define an operation which picks 
an element from a list according to the given probabilities: 

type ’a random = effect 

operation pick : (’a * float) list -> ’a 
end 

The operation pick accepts a finite probability distribution, represented as a list of 
pairs whose second components are nonnegative numbers that add up to 1. The handler 
which computes the expected value of a computation of type float is fairly simple 

let expectation r = handler 
| val v -> v 
I r#pick 1st k -> 

fold_right (fun (x,p) e -> e +. p *. k x) 1st 0.0 

Here fold_right is the list folding operation, e.g., fold_right f [a;b;c] x eval¬ 
uates as f a (f b (f c x)). 

Computing the distribution of results of a computation is not much more compli¬ 
cated: 

let combine = 

let scale p xs = map (fun (i, x) -> (i, p *. x)) xs in 
let rec add (i,x) = function 
I [] -> [(i,x)] 

I (j i y) : : 1st -> 

if i = j then (j,x+.y)::1st else (j,y)::add(i,x) 1st 
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fold_left 

(fun e (d,p) -> fold_right add (scale p d) e) [] 

let distribution r = handler 
| val v -> [(v, 1.8)] 

I r#pick 1st k -> 

combine (map (fun (x,p) -> (k x, p)) 1st) 

Here, combine is the multiplication for the distribution monad that combines a distri¬ 
bution of distributions into a single distribution. The function map is the famihar one, 
while fold_left is the left-handed counterpart of fold_right. 

As an example, let us consider the distribution of positions in a random walk of 
length 5, where we start at the origin, and step to the left, stay put, or step to the right 
with probabilities 2/10, 3/10 and 5/10, respectively. The distribution is computed by 

let r = new random in 
let x = new ref in 
with distribution r handle 
with state x 0 handle 
for i = 1 to 5 do 

x := !x + r#pick [(-1,0.2); (0,0.3); (1,0.5)] 
done ; 

Just like in the 8 queen example from Section |677| the handler for state must be enclosed 
by the distribution handler. We were surprised to see that the “wrong” order still works: 
let r = new random in 
let x = new ref in 
with state x 0 handle 
with distribution r handle 
for i = 1 to 5 do 

x := !x + r#pick [(-1,0.2); (0,0.3); (1,0.5)] 


How can this be? The answer is hinted at by eff which issues a warning about arbitrary 
sequencing of effects in the assignment to x. If we write the program with less syntactic 
sugar, we must decide whether to write the body of the loop as 
let a = !x in 

let b = r#pick [(-1,0.2); (0,0.3); (1,0.5)] in 


or as 

let b = r#pick [(-1,0.2); (0,0.3); (1,0.5)] in 
let a = !x in 
x := a + b 

In the first case a holds the value of x as it is before probabilistic choice happens, so 
update correctly reinstates the value of x, whereas in the second case it fails to do so. 
Indeed, we get the wrong answer if we swap the summands in the assignment to x and 
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handle state on the outside. On one hand we should not be surprised that the order in 
which effects happen matters, but on the other it is unsatisfactory that a simple change 
in the order of addition matters so much. Perhaps the sequencing warnings should be 
errors after all. 

6.10 Cooperative multithreading 

Cooperative multithreading is a model for parallel programming in which several threads 
run in parallel, but only one at a time. A new thread is created with a fork operation, 
a running thread relinquishes control with a yield operation, and a scheduler decides 
which thread runs next. As is well known, cooperative multithreading can be imple¬ 
mented in languages with first-class continuations. 

To get cooperative multithreadding in eff we first define an effect type with the 
desired operations: 

type coop = effect 

operation yield : unit -> unit 
operation fork : (unit -> unit) -> unit 
end 

Next we define a scheduler, in our case one that uses a round-robin strategy, as a han¬ 
dler: 

let round_robin c = 

let threads = ref [] in 

let enqueue t = threads := !threads @ [t] in 
let dequeue () = 

match !threads with 
I [] -> O 

I t :: ts -> threads := ts ; t () 

let rec scheduler () = handler 

| c#yield O k -> enqueue k ; dequeue () 

| c#fork t k -> 

enqueue k ; with scheduler () handle t () 

| val O -> dequeue O 

scheduler () 

The handler keeps a queue of inactive threads, represented as thunks. Note that dequeu¬ 
ing automatically activates the dequeued thunk. Yield enqueues the current thread, i.e., 
the continuation, and activates the first thread in the queue. Fork enqueues the current 
thread and activates the new one (an alternative would enqueue the new thread and re¬ 
sume the current one). The handler must not just activate the newly forked thread but 
also wrap itself around it, lest yield and fork triggered by the new thread go unhan¬ 
dled. Thus the definition of the handler is recursive. The val clause makes sure that 
the threads in the queue get a chance to run when the current thread terminates. 

Nothing prevents us from combining threads with other effects: threads may use 
common or private state, they may raise exceptions, inside a thread we can have another 
level of multithreading, etc. 
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6.11 Delimited control 


Our last example shows how to implement standard delimited continuations in eff. 
As a result we can transcribe code that uses continuations directly into eff , although 
we have found that transcriptions are typically cleaner and easier to understand if we 
modify them to use operations and handlers directly. 

We consider the static variant of delimited control that uses reset and shift m. 
The first operation delimits the scope of the continuation and the second one applies 
a function to it, from which it follows that one acts as a handler and the other as an 
operation. Indeed, the eff implementation is as follows: 

type (’a, ’b) delimited = 
effect 

operation shift : ((’a -> ’b) -> ’b) -> ’a 
end 

let rec reset d = handler 

| d#shift f k -> with reset d handle (f k) 

Since f itself may call shift, the handler wraps itself around f k. The standard 
useless example of delimited control is 
let d = new delimited in 
with reset d handle 

d#shift (fun k -> k (k (k 7))) *2+1 

The captured continuation k multiplies the result by two and adds one, thus the result is 
2 x (2 x (2 x 7+1) +1) +1 = 63. In Scheme the obligatory example of (undelimited) 
continuations is the “yin yang puzzle”, whose translation in eff is 

let y = new delimited in 
with reset y handle 
let yin = 

(fun k -> std#write ; k) (y#shift (fun k -> k k)) 

and yang = 

(fun k -> std#write "*" ; k) (y#shift (fun k -> k k)) 
yin yang 

The self-application k k is suspect, and eff indeed complains that it cannot solve the 
recursive type equation a = a —y ft. We have not implemented unrestricted recursive 
types, but we can turn off type checking, after which the puzzle prints out the same 
answer as the original one in Scheme. 


7 Discussion 

Our purpose was to design a programming language based on the algebraic approach 
to computational effects and their handlers. We feel that we succeeded and that our 
experiment holds many promises. 
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First, we already pointed out several times that eff would benefit from an effect 
system that provided a static analysis of computational effects. However, for a useful 
result we need to find a good balance between expressivity and complexity. 

Next, it is worth investigating how to best reason about programs in eff. Because 
the language has been inspired by an algebraic point of view, it seems clear that we 
should look into equational reasoning. The general theory has been investigated in 
some detail lH5lfT7l . but the addition of effect instances may complicate matters. 

Finally, continuations are the canonical example of a non-algebraic computational 
effect, so it is a bit surprising that eff provides a flexible and clean form of delimited 
control, especially since continuations were not at all on our design agenda. What then 
can we learn from eff about control operators in an effectful setting? 
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